Subject: Year 2000 Compliance and the SNA Architecture

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 20 Aug 1996 17:11:00 -0400

I suppose we should have started discussing this before, and I am certain
that the topic must have come up inside IBM.  Is the SNA Architecture itself
Year 2000 compliant? 

IBM can deal with the portions of the architecture that are proprietary to
them, I am sure they still remember January 1, 1980 when every NCP in the
world crashed a few minutes after midnight when it received the Date and
Time SETCV from VTAM.  Note however that Date and Time CV carried by that RU
still only carries a two digit year (reference LY43-0081-2).

In the open portions of the architecture there are a few cases of 2 digit
years:

  The Date/Time (X'01') MS Common Subvector carries "Year, in binary,
  consisting of the last two digits of the year".  This is in binary, so
  that if it was redefined as "Year - 1900, in binary" it would continue
  working until the year 2155.  Indeed since the code is a little simpler,
  it would not surprise me if some of the implementations out there actually
  do (Year-1900) rather than (Year%1900).  Interestingly this subvector was
  completely redesigned between May 1985 and June 1987 and yet the 2 digit
  limitation was retained at that time.  This was a questionable decision
  especially considering that this information is not carried on the data 
  path.  Since this vector now consists of a series of subvectors, a new
  subvector format could also be introduced with the full year.

  The Software Product Customization Date and Time (X'09') subfield of the
  Product ID (X'11') MS Common Subvector carries "Year in unsigned packed
  deciomal (i.e., one hex digit for each decimal digit)" but this is a one
  byte field, so despite the absence of an explicit statement, this clearly
  carries only the low order two digits.  This subfield layout was defined
  between December 1983 and May 1985.  There is no room for expansion of
  the date.  A whole new subfield format will need to be defined to support
  a four digit year.

Those are just the ones that are identified in the table of contents as
carrying dates.  Someone who has access to a machine readable copy of the
documentation could do a search for all occurrences of the word "year".

Jim Cobban   |  [email-masked]                   |  Phone: (613) 763-8013
Nortel (MCS) |                                      |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Nortel.                                         |

---

From: Bob Clouston <[email-masked]>
Date: Tue, 20 Aug 1996 21:39:54 -0400 (EDT)

Good question to ask.

As you say, the Date/Time SV will accomodate to 2155.  If products wrap
to 00 at 2000, they should be fixed.  I think NetView uses its own 
time stamp rather than the Date/Time SV anyway, even if it doesn't
it shouldn't crash.  It could be tolerant enough to 
recognize any value < 80 as 2000+value if products are found to
be in error.  I'm pretty sure NetView itself went through a 
year 2000 review a few years back.
Full representation of the year is better but accomodating to 2155
seems good enough.

The PSID has a length limit of 60, at least when carried in an XID 
because of a limit on the XID size itself.
This is why the SV11 sf09 was kept small.  Obviously this could
have been done better.  Its really an information only field, used
to time stamp customized software, and is not used in any ordering
scheme.  00 can be easily interpreted as 2000.  
As stated, this field never breaks, it just doesn't have a way to 
state the century.  I don't see a need to expand this to a 4 digit
year since most products probably push the 60 byte limit already.

Another timestamp field is the UOW Date/Time sf, back in the SNA/DS 
encodings.  It has a 2-byte binary year field, 1999 = x'07cf', 
2000 = x'07d0'.  So it is ok for longer than even Zager and Evans
can foresee (anybody else remember that song?).

I think the rest of the architecture uses relative sequence 
numbers where time sequencing is important, such as RSNs and FRSNs 
in TDUs.  Anybody else see other issues?

Bob Clouston
Cisco Systems